Light ROM 4/Light ROM 4 - Disc 1.iso/text/maillist/1995/0695.doc/[e-mail]_Tue Jun 20 00:52:26 1995.msg

Internet Message Format | 1995-07-04 | 3KB

Received: by webcom.com
    (1.37.109.15/16.2) id AA061951802; Mon, 19 Jun 1995 10:10:03 -0700
Return-Path: <[e-mail]>
Received: from earth.usa.net by webcom.com with ESMTP
    (1.37.109.15/16.2) id AA061801792; Mon, 19 Jun 1995 10:09:52 -0700
Received: (from jgjones@localhost) by earth.usa.net (8.6.10/8.6.10) id LAA17562 for [e-mail]; Mon, 19 Jun 1995 11:10:32 -0600
Date: Mon, 19 Jun 1995 11:10:32 -0600
From: James Jones/Nibbles and Bits <[e-mail]>
Reply-To: James Jones/Nibbles and Bits <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Content-Type: text
Content-Length: 2278
Sender: [e-mail]
Precedence: bulk

[e-mail] said:

>Okay, I have -one-.  It's specifically a field rendering problem, and
>not something that flipping fields will solve.  This is a little hard
>to diagram in ASCII-Vision, but consider the following:
>
>(1 2) (3 4) (5 6)
>
>Each pair of numbers represents a frame with two fields.  The fields
>are 1/60 of a second apart, so whatever it is we're counting with those
>numbers, it advances by one per field and two per frame.  (Buying this
>so far?)  If you're ready to reverse at this point, what's the next
>frame?
>
>If we use (3 4) we get a jump from 6 to 3:
>
>... (5 6) (3 4) ...
>
>If we reverse fields and use (4 3), we get a jump from 6 to 4:
>
>... (5 6) (4 3) ...
>
>See?  What we really want is
>
>... (5 6) (5 4) ...

   Wouldn't you have, upon rendering the same frames with flip fields on:

      (1 2) (3 4) (5 6) (6 5) (4 3) (2 1)    ?

   Also there's the "screen position" of the fields to consider:
   If you have, for example,

   Frame 1    Field A  (Even scan lines)
              Field B  (Odd scan lines)

   Frame 2    Field A  (Even scan lines)
              Field B  (Odd scan lines)

   ...etc...

   ...and if you filp the fields, not only the order, but the relative
position of each field's scan lines have changed, thus transposing
each field image up or down by one pixel line.
   An Abekas, for example, wants to see the fields in a particular
order and, apparently, assigns each field to a different group of scan
lines than lightwave assigns them. I don't know exactly what's going
on in this situation, but it looks REALLY BAD.

   Maybe it would be handy if LW could not only flip fields, but
offset the field dominance by one.
   Of course, if LW could render little frame/field identifying
numbers in the overscan area of each field, it might be easier to
figure out what's going on with these type of problems. (Sounds like a
good idea for a plug-in. Hint, hint.)

   I wonder if motion-blurred (not field-rendered) frames have the
same problem? In other words, is motion-blur perfectly symetrical?
   (I should try it and find out, I guess... :)

   -Jim
James G. Jones
Nibbles & Bits
[e-mail]

___
* UniQWK #5134*

--
James Jones/Nibbles and Bits <[e-mail]> sent this message.
To Post a Message           : [e-mail]
Un/Subscription Requests To : [e-mail]
(DIGEST)                 or : [e-mail]
Administrative Items To     : [e-mail]